Two-way radio communication systems such as land mobile radio (LMR) have been in use for many years. With conventional LMR, users typically communicate with each other using hardware devices comprising at least one base station or dispatching unit and one or more transmitting/receiving (TR) devices, such as mobile radios (MR's). MR's typically comprise hand-held portables, vehicle-installed radios, and the like, and to communicate with each other, users of the system select a predetermined frequency over which to transmit and receive messages via the base station.
LMR's are frequently used by police and fire departments, rescue workers, paramedics, power and telephone company field technicians, municipalities, and other mobile groups that require immediate communication with other members of their respective groups. Communication between the various members can also include visual information, which may be displayed on another TR device called a mobile data terminal (MDT). MDT's include portable devices such as a laptop computer, a personal digital assistant (PDA), or other portable data device that is associated with an MR. For example, a police officer may request and receive information from a computer located at the police station about a stopped motorist, which is displayed on an MDT in the officer's patrol car via the officer's MR.
FIG. 1 illustrates a typical LMR environment. Referring to FIG. 1, individual units of various groups (e.g., emergency vehicles, fire vehicles, police vehicles, and handheld users) communicate with each other (both within and possibly outside of their own group) using MR's (e.g., a vehicle mounted MR 120 and a handheld MR 124 in FIG. 1) over shared radio channels coordinated by a central controller 100. If desired, MDT's can be paired with any of the MR's so that visual information can be transmitted and received over the LMR system. In FIG. 1, MR 120 is paired with MDT 122, and MR 124 is paired with MDT 126.
Central controller 100 can comprise a dispatch console housed directly at a base station or may be remotely located via other communication facilities (e.g., landline connections) as will be appreciated by those in the art. There may also be multiple dispatch consoles (e.g., one for each separate fleet) and a master or supervisory dispatch console for the entire system as will also be appreciated by those in the art. The details of the operation of such a system, as well as the hardware and/or software for building such a system are well known and are not discussed in detail herein.
In early systems, each channel was assigned a dedicated frequency. Thus, for example, all persons utilizing channel 10 in the system would transmit and receive messages on the same frequency. While this functioned adequately when a small number of users used the system, as the popularity of two-way radio systems grew, the pre-assigned channels became congested and difficult to use, and privacy was limited so that anyone could easily listen in on communications over the channels.
The spectral inefficiency of conventional two-way radio systems led to the development of “trunked” systems. Trunking is a method of using relatively few communication paths for a large number of potential users. Trunking systems allow for the automatic sharing of a “pool” of frequencies assignable to multiple radio channels among a group of users.
In a typical trunking system, each MR has a unique identifier (“logical ID” or “LID”), and multiple MR's may be designated as being part of a group (e.g., all firefighters) with a corresponding group identifier (group ID or GID). A user of an MR wishing to transmit a voice communication to another MR or group of MR's inputs a LID (for an individual MR) or a GID (for a group of MR's) for the target (i.e., receiving) radio(s), e.g., via a keypad on the MR or any other known means for inputting an ID. In a known manner, the central controller assigns a frequency from the frequency pool for the transmission, and when the transmission is complete, the frequency is “returned” to the pool.
A control frequency (also referred to as a “control channel”) is allocated to send signals that coordinate the use of the MR's within the system. In FIG. 1, control channel 130 performs this function for MR 120, and control channel 136 performs this function for MR 124. The MR's constantly monitor the control channel for instructions from the central controller 100. When a voice call is initiated from a radio in the system (e.g., by pressing the “push-to-talk” (PTT) button on the MR) the LID's of the transmitting and target radios are transmitted on the control frequency to the central controller. The central controller uses the LID information to assign a voice “working” frequency (also called a “working channel”) for the voice transmission between the transmitting and target radios. In FIG. 1, the working channel for a voice transmission from MR 120 to central controller is illustrated by transmit (TX) and receive (RX) lines 132. Likewise, the working channel for voice communications between MR 124 and central controller 100 is illustrated by TX and RX lines 138. The concept of trunking radio systems and their use of LID's and GID's is well known. The focus of the present application is on the manner in which the LID's and GID's are assigned, and in particular, how they are assigned in a well-known system called the Enhanced Digital Access Communications System (EDACS).
EDACS is a well known, extremely flexible trunked communication system designed to provide secure, reliable two-way radio communications for public safety, utility, government, military, and business and industrial organizations. EDACS allows the transmission and receiving of voice and data communications and allows users to make and receive telephone calls over the system via fixed handsets or cordless telephones. An interface between MR's in an EDACS system and their associated MDT's is necessary for flow control. Key to the operation of EDACS is the Radio Digital Interface (RDI) and the RDI protocol. The RDI protocol is a protocol that functions with the RDI (a known hardware device) to facilitate the flow of data between an MR and its associated MDT. The RDI protocol functions with RDI hardware to maximize data throughput in the EDACS system by handling all system acknowledgments and message retries necessary to ensure that data is transported correctly and without errors. Typically, the MDT uses a 9600 bps serial interface of the RDI hardware to connect to the MR. The MR's can contain an internal RDI or an external RDI. The RDI protocol is simply a flow control protocol and, as such, has no effect on the content of the message.
Under the RDI protocol, a request to send a block of data from the MDT to the MR, or vice versa, is referred to as an “XFERB command”. The RDI-protocol-specific information is not transmitted over the RF interface (the RF coupling between the MR and the central controller), rather, the RDI protocol serves only to transfer the block of data and associated call information between the MR and the MDT. In an outgoing data transfer from an MDT to an MR, the LID sent via the RDI protocol identifies the target MR that will receive the data and transfer the data to its MDT. It is subsequently included by the transmitting MR, along with its own LID, in a call request over the control channel. The processor that manages the control channel (not shown) assigns a data working channel for the data transmission, and the block of data that was sent to the transmitting MR from the transmitting MDT, via the RDI protocol, is then sent over the data working channel to the central controller.
In FIG. 1, if we assume a data transmission from MDT 122 to MDT 126, the LID of receiving MDT 122 would be sent over the RDI interface to transmitting MR 120. Transmitting MR 120 would then add its own LID and transmit both LID's over the control channel 130 to central controller 100. Central controller 100 would then establish a data working channel, illustrated by TX and RX lines 134, over which MR 120 would send the data. In a similar (but reverse) manner, central controller 100 then sets up a data working channel 140 to receiving MR/MDT pair 124/125. When received by receiving MR 124, the LID of the transmitting MR 120 is also received as part of the transmission, so that the receiving MR/MDT pair 124/125 knows the origin of the transmission.
An example of a typical XFERB command is illustrated in FIG. 2 and is described in more detail below. An XFERB command under the RDI protocol comprises a sequence of fifteen (15) decimal (0–9) numbers divided into command “fields,” with each field in the sequence having a predetermined “role” in the command. The XFERB command follows the structure “mc00tgggggnnnnn” where “m” refers to the “mode” field; “c” refers to the “ACK2” field (a request that the receiver respond with a positive acknowledgment upon receipt of the data); “00” (reserved placeholders); “t” refers to the “call type” field; “g” refers to one of the five numbers of the LID or GID field; and “n” refers to one of the four numbers in the “data binary bytes” field (indicating the size of the data block to be sent). Thus, in the example XFERB command of FIG. 2, the mode field 202 is “Standard XFERB” (1); the ACK2 field 204 is “Standard Sequence Implemented” (0); the placeholders (00) are in field 206; the call type field 208 is “Individual Call” (2); the LID field 210 is “16238”; and the data binary bytes field 212 are “0032”. The complete sequence is thus 10002162380032.
Because each radio has a unique LID number, it is possible to address any individual radio from the dispatch center or from another radio unit that has the authority to do so. In the standard configuration, EDACS allows 16384 (214) individual users (LID Nos. 0–16383) to be defined in the system. Since five decimal digits (ggggg) are allocated to the ID numbers, theoretically a maximum number of 100,000 individual users (LID Nos. 00000 to 99999) could be defined in an EDACS system, if the RDI protocol were modified to allow the user ID numbers to exceed 16383.
A problem exists if it is desired to configure a system to be able to define more than 100,000 users. The XFERB command message used by the RDI protocol identifies a fixed-length and format (five decimal digits) for ID numbers, and many systems are now in place throughout the world that utilize this protocol. While the RDI protocol could be modified so that more than five decimal digits are available to specify the LID destination address, there would not be compatibility between the current system and a more-than-five-decimal-digit system. For example, a system using the current protocol would register an error condition upon receipt of a LID segment of more than 5 digits in size.
Accordingly, there is a need for a method and system for designating more than 100,000 LID's without changing the structure of the command message containing the LID.